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Analizo un exitoso proyecto de software libre (fetchmail), que fue realizado para probar 
deliberadamente algunas sorprendentes ideas sobre la ingenieria de software sugeridas por la 
historia de Linux. Discuto estas teorias en terminos de dos estilos de desarrollo 
fundamentalmente opuestos: el modelo catedral de la mayoria de los fabricantes de software 
comercial contra el modelo bazar del mundo Linux. Demuestro que estos modelos parten de 
puntos de vista contrapuestos acerca de la naturaleza de la tarea de depuracion del software. 
Posteriormente, hago una argumentacion, a partir de la experiencia de Linux, de la siguiente 
sentencia: "si se tienen las miradas suficientes, todas las pulgas saltardn a la vista". Al final, 
sugiero algunas fructiferas analogias con otros sistemas autoregulados de agentes egoistas, y 
concluyo con una somera exploracion de las implicaciones que pude tener este enfoque en el 
futuro del software. 

1. La Catedral y el Bazar 

Linux es subversive). «<,Quien hubiera pensado hace apenas cinco anos que un sistema operativo 
de talla mundial surgiria, como por arte de magia, gracias a la actividad hacker desplegada en 
ratos libres por varios miles de programadores diseminados en todo el planeta, conectados 
solamente por los tenues hilos de la Internet? 

Lo que si es seguro es que yo no. Cuando Linux aparecio en mi camino, a principios de 1993, 
yo tenia invertidos en UNIX y el desarrollo de software libre alrededor de diez anos. Fui uno de 
los primeros en contribuir con GNU a mediados de los ochentas y he estado aportando una 
buena cantidad de software libre a la red, desarrollando o colaborando en varios programas 
(NetHack, los modos VC y GUD de Emacs, xlife y 

otros) que todavia son ampliamente usados. Crei que sabia como debfan hacerse las cosas. 

Linux vino a trastocar buena parte de lo que pensaba que sabia. Habia estado predicando 
durante anos el evangelio UNIX de las herramientas pequenas, de la creacion rapida de 
prototipos y de la programacion evolutiva. Pero tambien creia que existia una determinada 
complejidad critica, por encima de la cual se requeria un enfoque mas planeado y centralizado. 
Yo pensaba que el software de mayor envergadura (sistemas operativos y herramientas 
realmente grandes, tales como Emacs) requeria construirse como las catedrales, es decir, que 
debia ser cuidadosamente elaborado por genios o pequenas bandas de magos trabajando 
encerrados a piedra y lodo, sin liberar versiones beta antes de tiempo. 

El estilo de desarrollo de Linus Torvalds ("libere rapido y a menudo, delegue todo lo que 
pueda, sea abierto hasta el punto de la promiscuidad") me cayo de sorpresa. No se trataba de 
ninguna forma reverente de construir la catedral. Al contrario, la comunidad Linux se asemejaba 
mas a un bullicioso bazar de Babel, colmado de individuos con propositos y enfoques dispares 
(fielmente representados por los repositorios de archivos de Linux, que pueden aceptar 
aportaciones de quien sea), de donde surgiria un sistema estable y coherente unicamente a partir 
de una serie de artilugios. 

El hecho de que este estilo de bazar parecia funcionar, y funcionar bien, realmente me dejo 
sorprendido. A medida que iba aprendiendo a moverme en ese medio, no solo trabaje 
arduamente en proyectos individuales, sino en tratar de comprender por que el mundo Linux no 
naufragaba en el mar de la confusion, sino que se fortalecia con una rapidez inimaginable para 
los constructores de catedrales. 



Cref empezar a comprender a mediados de 1996. El destino medio un medio perfecto para 
demostrar mi teoria, en la forma de un proyecto de software libre que trataria de realizar 
siguiendo el estilo del bazar de manera consciente. Asi lo hice y resulto un exito digno de 
consideration. 

En el resto de este articulo relatare la historia de este proyecto, y la usare para proponer algunos 
aforismos sobre el desarrollo real del software libre. No todas estas cosas fueron aprendidas del 
mundo Linux, pero veremos como fue que les vino otorgar un sentido particular. Si estoy en lo 
cierto, le serviran para comprender mejor que es lo que hace a la comunidad linuxera tan buena 
fuente de software; y le ayudaran a ser mas productivo. 

2. El correo tenia que llegar 

Desde 1993 he estado encargado de la parte tecnica de un pequeno ISP de acceso gratuito 
llamado Chester County InterLink (CCIL), en West Chester, Pennsylvania (fui uno de los 
fundadores de CCIL y escribi su original software BBS multiusuario, el cual puede verse 
entrando a telnet://locke.ccil.org . Actualmente soporta mas de tres mil usuarios en 19 lfneas). 
Este empleo me permitio tener acceso a la red las 24 horas del dia a traves de la lfnea de 56K de 
CCIL, jde hecho, practicamente el me lo demandaba!. 

Para ese entonces ya me habi habituado al correo electronico. Por diversas razones fue diffcil 
obtener SLIP para enlazar mi maquina en casa (snark.thyrsus.com) y CCIL. Cuando finalmente 
pude lograrlo, encontre que era particularmente molesto tener que entrar por telnet a locke cada 
rato para revisar mi correo. Lo que queria era que fuera reenviado a snark para que biff ( 1 ) me 
notificase cuando llegara. 

Un simple redireccionamiento con sendmail no iba a funcionar debido a que snark no siempre 
esta en lfnea y no tiene una direction IP estatica. Lo que necesitaba era un programa que saliera 
por mi conexion SLIP y trajera el correo hasta mi maquina. Yo sabia que tales programas ya 
existfan, y que la mayoria usaba un protocolo simple llamado POP (Post Office Protocol, 
Protocolo de Oficina de Correos), de tal manera que me cerciore que el servidor P0P3 estuviera 
en el sistema operativo BSD/OS de locke. 

Necesitaba un cliente P0P3; de tal manera que lo busque en la red y encontre uno. En realidad 
halle tres o cuatro. Use pop-perl durante un tiempo, pero le faltaba una caracterfstica a todas 
luces evidente: la capacidad de identificar las direcciones de los correos recuperados para que las 
respuestas pudieran darse correctamente. 

El problema era este: supongamos que un tal monty en locke me envia un correo. Si yo lo 
jalaba desde snark y luego intentaba responder, entonces mi programa de correos dirigfa la 
respuesta a un monty inexistente en snark. La edition manual de las direcciones de respuesta 
para pegarles el '@ccil.org', muy pronto se volvio algo muy molesto. 

Era evidente que la computadora tenia que hacer esto por mi. (De hecho, de acuerdo con 
RFC1123, section 5.2.18, sendmail deberia de estarlo haciendo.) jSin embargo, ninguno de los 
clientes POP lo hacia realmente! Esto nos lleva a la primera lection: 

1. Todo buen trabajo de software comienza a partir de las necesidades personates del 
programador. (Todo buen trabajo empieza cuando uno tiene que rascarse su propia comezon) 



Esto podria sonar muy obvio: el viejo proverbio dice que "la necesidad es la madre de todos los 
inventos". Empero, hay muchos programadores de software que gastan sus dias, a cambio de un 
salario, en programas que ni necesitan ni quieren. No ocurre lo mismo en el mundo Linux; lo 
que sirve para explicar por que se da una calidad promedio de software tan alta en esa 
comunidad. 

Por todo esto, ^pensaran que me lance inmediatamente a la voragine de escribir, a partir de 
cero, el programa de un nuevo cliente POP3 que compitiese con los existentes? jNunca en la 
vida! Revise cuidadosamente las herramientas POP que tenia al alcance, preguntandome "^cual 
se aproxima mas a lo que yo necesito?", porque 

2. Los buenos programadores saben que escribir. Los mejores, que reescribir (y reutilizar). 

Aunque no presumo ser un extraordinario programador, he tratado siempre de imitar a uno de 
ellos. Una importante caracterfstica de los grandes programadores es la 

meticulosidad con la que construyen. Saben que les pondran diez no por el esfuerzo, sino por 
los resultados; y que casi siempre sera mas facil partir de una buena solution partial que de 
cero. 

Linus, por ejemplo, no intento escribir Linux partiendo de cero. En vez de eso, comenzo por 
reutilizar el codigo y las ideas de Minix, un pequeno sistema operativo (OS) tipo UNIX hecho 
para maquinas 386. Eventualmente termino desechando o reescribiendo todo el codigo del 
Minix, pero mientras conto con el le sirvio como una importante plataforma de lanzamiento del 
proyecto en gestation que posteriormente se convertiria en Linux. 

Con ese espfritu, comence a buscar una herramienta POP que estuviese razonablemente escrita 
para ser usada como plataforma initial para mi desarrollo. 

La tradition del mundo UNIX de compartir las fuentes siempre se ha prestado a la reutilizacion 
del codigo (esta es la razon por la que el proyecto GNU escogio a UNIX como su OS base, pese 
a las serias reservas que se tenian). El mundo Linux ha asumido esta tradition hasta llevarla muy 
cerca de su limite tecnologico; posee terabytes de codigo fuente que estan generalmente 
disponibles. Asi que es mas probable que la busqueda de algo bueno tenga mayores 
probabilidades de exito en el mundo Linux que en ningun otro lado. 

Asi sucedio en mi caso. Ademas de los que habia encontrado antes, en mi segunda busqueda 
consegui un total de nueve candidatos: fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, 
pope, popmail y upop. El primero que elegf fue el 'fetchpop', un programa de Seung-Hong Oh. 
Le agregue mi codigo par que tuviera la capacidad de reescribir los encabezados y varias 
mejoras mas, las cuales fueron incorporadas por el propio autor en la version 1.9. 

Sin embargo, unas semanas despues me tope con el codigo fuente de 'popclient', escrito por 
Carl Harris, y descubri que tenia un problema. Pese a que fetchpop poseia algunas ideas 
originales (tal como su modo demonio), solo podia manejar POP3, y estaba escrito a la manera 
de un aficionado (Seung-Hong era un brillante programador, pero no tenia experiencia, y ambas 
caracterfsticas eran palpables). El codigo de Carl era mejor, bastante profesional y robusto, pero 
su programa carecia de varias de las caracterfsticas importantes del fetchpop que eran diffciles 
de implementar (incluyendo las que yo mismo habia agregado). 

^Segufa o cambiaba? Cambiar significaba desechar el codigo que habia anadido a cambio de 
una mejor base de desarrollo. 



Un motivo practico para cambiar fue la necesidad de contar con soporte de multiples 
protocolos. POP3 es el protocolo de servidor de correos que mas se utiliza, pero no es el unico. 
Fetchpop y otros no manejaban POP2, RPOP 6 APOP, y yo tenia ya la idea vaga de anadir 
IMAP (Protocolo de Acceso a Mensajes por Internet, el protocolo de correos mas poderoso y 
reciente) solo por entretenimiento. 

Pero habia una razon mas teorica para pensar que el cambio podia ser una buena idea, algo que 
aprendi mucho antes de Linux: 

3. "Contemple desecharlo; de todos modos tendrd que hacerlo. " 
(Fred Brooks, The Mythical Man— Month, Capitulo 11) 

Diciendolo de otro modo: no se entiende cabalmente un problema hasta que se implementa la 
primera solucion. La siguiente vez quizaas uno ya sepa lo suficiente para solucionarlo. Asi que 
si quieres resolverlo, disponte a empezar de nuevo al menos una vez. 

Bien, me dije, los cambios a fetchpop fueron un primer intento, asi que cambio. 

Despues de enviarle mi primera serie de mejoras a Carl Harris, el 25 de junio de 1996, me 
entere que el habia perdido el interes por popclient desde hacia rato. El programa estaba un poco 
abandonado, polvoriento y con algunas pulgas menores colgando. Como se le tenfan que hacer 
varias correcciones, pronto acordamos que lo mas logico era que yo asumiera el control del 
proyecto. 

Sin darme cuenta, el proyecto habia alcanzado otras dimensiones. Ya no estaba intentando 
hacerle unos cuantos cambios menores a un cliente POP, sino que me habia hecho responsable 
de uno; y las ideas que bullfan en mi cabeza me conducirfan probablemente a cambios mayores. 

En una cultura del software que estimula el compartir el codigo fuente, esta era la forma natural 
de que el proyecto evolucionara. Yo actuaba de acuerdo con lo siguiente: 

4. Si tienes la actitud adecuada, encontrards problemas interesantes. 
Pero la actitud de Carl Harris fue aun mas importante. El entendio que 

5. Cuando se pierde el interes en un programa, el ultimo deber es heredarlo a un sucesor 
competente. 

Sin siquiera discutirlo, Carl y yo sabfamos que el objetivo comun era obtener la mejor solucion. 
La unica duda entre nosostros era si yo podia probar que el proyecto iba a quedar en buenas 
manos. Una vez que lo hice, el actuo de buena gana y con diligencia. Espero comportarme igual 
cuando llegue mi turno. 

3. La importancia de contar con usuarios 

Asi fue como herede popclient. Ademas, recibi su base de usuarios, lo cual fue tan o mas 
importante. Tener usuarios es maravilloso. No solo porque prueban que uno esta satisfaciendo 
una necesidad, que ha hecho algo bien, sino porque, cultivados adecuadamente, pueden 
convertirse en magnfficos asistentes. 



Otro aspecto importante de la tradition UNIX, que Linux, de nuevo, lleva al lfmite, es que 
muchos de los usuarios son tambien hackers, y, al estar disponible el codigo fuente, se vuelven 
hackers muy efectivos. Esto puede resultar tremendamente util para reducir el tiempo de 
depuration de los programas. Copn un buen estimulo, los usuarios diagnosticaran problemas, 
sugeriran correcciones y ayudaran a mejor los programas mucho mas rapido de lo que uno lo 
haria sin ayuda. 

6. Tratar a los usuarios como colaboradores es la forma mas apropiada de mejorar el codigo, 
y la mas efectiva de depurarlo. 

Suele ser facil subestimar el poder de este efecto. De hecho, es posible que todos continuasemos 
desestimando la capacidad multiplicadora que adquiriria con el numero de usuarios y en contra 
de la complejidad de los sistemas, hasta que asi nos lo 

vino a demostrar Linus. 

En realidad, considero que la genialidad de Linus no radica en la construction mismo del kernel 
de Linux, sino en la invention del modelo de desarrollo de Linux. Cuando en una ocasion 
exprese esta opinion delante de el, sonrio y repitio quedito una frase que ha dicho muchas veces: 
"Basicamente soy una persona muy floja que le gusta obtener el credito por lo que, realmente, 
hacen" los demas. Flojo como una zorra. O, como diria Robert Heinlein, demasiado flojo para 
fallar. 

En retro spectiva, un precedente de los metodos y el exito que tiene Linux podria encontrarse en 
el desarrollo de las bibliotecas del Emacs GNU, asi como los archivos del codigo de Lisp. En 
contraste con el estilo de construction catedral del nucleo del Emacs escrito en C, y de muchas 
otras herramientas de la FSF, la evolution del codigo de Lisp fue bastante fluida y, en general, 
dirigida por los propios usuarios. Las ideas y los prototipos de los modos se rescribfan tres o 
cuatro veces antes de alcanzar su forma estable final. Mientras que las frecuentes colaboraciones 
informales se hacfan posibles gracias a la Internet, al estilo Linux. 

Es mas, uno de mis programas con mayor exito, antes de fetchmail, fue probablemente el modo 
VC para Emacs, una colaboracion tipo Linux, que realice por correo electronico conjuntamente 
con otras tres personas, de las cuales solamente he conocido a una (Richard Stallman) hasta la 
fecha. VC era una front-end para SCCS, RCS y posteriormente CVS, que ofrecia controles de 
tipo "al toque" para operaciones de control de versiones desde Emacs. Era el desarrollaba de un 
pequeno y, hasta cierto punto, rudimentario modo sccs.el que alguien habia escrito. El desarrollo 
de VC tuvo exito porque, a diferencia del Emacs mismo, el codigo de Emacs en Lisp podia 
pasar por el ciclo de publicar, probar y depurar, muy rapidamente. 

(Uno de los efectos colaterales de la polftica de la FSF de atar legalmente el codigo a la GPL, 
fue que se volvio mas diffcil para la FSF usar el modo bazar, debido a su idea de que se debin de 
asignar derechos de autor por cada contribution individual de mas de veinte lfneas, a fin de 
inmunizar al codigo protegido por la GPL de cualquier problema legal surgido de ley de 
derechos de autor. Los usuarios de las licencias BSD y del MIT X Consortium no tienen este 
problema, debido a que no intentan reservarse derechos que cualquiera intente poner en duda.) 

4. Libere rapido y a menudo 

Las publicaciones rapidas y frecuentes del codigo constituyen una parte critica del modelo 
Linux de desarrollo. La mayorfa de los programadores, en los que me incluyo, creia antes que 
era una mala polftica involucrarse en proyectos mas grandes triviales, debido a que las primeras 



versiones, casi por definition, salen plagadas de errores, y a nadie le gusta agotar la paciencia de 
los usuarios. 

Esta idea reafirmaba la preferencia de los programadores por el estilo catedral de desarrollo. Si 
el objetivo principal era que los usuarios vieran la menor cantidad de errores, entonces solo habi 
que liberar una vez cada seis meses (o aun con menos 

frecuencia) y trabajar como burro en la depuration en el interin de las versiones que se saquen a 
la luz. El nucleo del Emacs escrito en C se desarrollo de esta forma. No asi la biblioteca de Lisp, 
ya que los repositorios de los archivos de Lisp, donde se podfan conseguir versiones nuevas y en 
desarrollo del codigo, independientemente del ciclo de desarrollo del Emacs, estaban fuera del 
control de la FSF. 

El mas importante de estos archivos fue el elisp de la Universidad Estatal de Ohio, el cual se 
anticipo al espfritu y a muchas de las caracteristicas de los grandes archivos actuales de Linux. 
Pero solamente algunos de nosotros reflexionamos realmente acerca de lo que estabamos 
haciendo, o de lo que la simple existencia del archivo sugeria sobre los problemas implfcitos en 
el modelo de desarrollo estilo catedral de la FSF. Yo realice un intento serio, alrededor de 1992, 
de unir formalmente buena parte del codigo de Ohio con la biblioteca Lisp oficial del Emacs. 
Me meti en broncas politicas muy serias y no tuve exito. 

Pero un ano despues, a medida que Linux se agigantaba, quedo claro que estaba pasando algo 
distinto y mucho mas sano. La polftica abierta de desarrollo de Linus era lo mas opuesto a la 
construction estilo catedral. Los repositorios de archivos en sunsite y tsx-11 mostraban una 
intensa actividad y muchas distribuciones de Linux circulaban. Y todo esto se manejaba con una 
frecuencia en la publication de programas que no tenia precedentes. 

Linus estaba tratando a sus usuarios como colaboradores de la forma mas efectiva posible: 

7. Libere rdpido y a menudo, y escuche a sus clientes. 

La innovation de Linus no consistio tanto en esto (algo parecido habia venido sucediendo en la 
tradition del mundo UNIX desde hacia tiempo), sino en llevarlo a un nivel de intensidad que 
estaba acorde con la complejidad de lo que estaba desarrollando. ;En ese entonces no era raro 
que liberara una nueva version del kernel mas de una vez al dia! Y, debido a que cultivo su base 
de desarrolladores asistentes y busco colaboracion en la Internet mas intensamaente que ningun 
otro, funciono. 

^Pero como fue que funciono? ^Era algo que yo podia emular, o se debia a la genialidad unica 
de Linus? 

No lo considero asi. Esta bien, Linus es un hacker endiabladamente astuto (^cuantos de nosotros 
podrfan disenar un kernel de alta calidad?). Pero Linux en si no representa ningun salto 
conceptual sorprendente hacia delante. Linus no es (al menos, no hasta ahora) un genio 
innovador del diseno como lo son Richard Stallman o James Gosling. En realidad, para mi Linus 
es un genio de la ingenieria; tiene un sexto sentido para evitar los callejones sin salida en el 
desarrollo y la depuration, y es tipo muy sagaz para encontrar el camino con el minimo esfuerzo 
desde el punto A hasta el punto B. De hecho, todo el diseno de Linux transpira esta calidad, y 
refleja un Linus conservador que simplifica el enfoque en el diseno. 

Por lo tanto, si las publicaciones frecuentes del codigo y la busqueda de asistencia dentro de la 
Internet no son accidentes, sino partes integrales del ingenio de Linus para ver la rata critica del 



minimo esfuerzo, «<,que era lo que estaba maximizando? <j,Que era lo que estaba exprimiendo de 
la maquinaria? 

Planteada de esta forma, las pregunta se responde por si sola. Linus estaba manteniendo a sus 
usuarios-hackers-asistentes constantemente estimulados y recompensados por la perspectiva de 
tomar parte en la accion y satisfacer su ego, premiado con la exhibition y mejora constante, casi 
diaria, de su trabajo. 

Linus apostaba claramente a maximizar el numero de horas-hombre invertidas en la depuracion 
y el desarrollo, a pesar del riesgo que coma de volver inestable el codigo y agotar a la base de 
usuarios, si un error serio resultaba insondable. Linus se portaba como si creyera en algo como 
esto: 

8. Dada una base suficiente de desarrolladores asistentes y beta— testers, casi cualquier 
problema puede ser caracterizado rdpidamente, y su solution ser obvia at menos para alguien. 

O, dicho de manera menos formal, "con muchas miradas, todos los errores saltaran a la vista". 
A esto lo he bautizado como la Ley de Linus. 

Mi formulation original rezaba que todo problema debera ser transparente para alguien. Linus 
descubrio que la personas que entendian y la que resolvfan un problema no eran necesariamente 
las mismas, ni siquiera en la mayoria de los casos. Decia que "alguien encuentra el problema y 
otro lo resuelve". Pero el punto esta en que ambas cosas suelen suceder con gran rapidez. 

Aqui, pienso, subyace una diferencia esencial entre el estilo del bazar y el de la catedral. En el 
enfoque estilo catedral de la programacion, los errores y problemas de desarrollo son fenomenos 
truculentos, insidiosos y profundos. Generalmente toma meses de revision exhaustiva para unos 
cuantos el alcanzar la seguridad de que han sido eliminados del todo. Por eso se dan los 
intervalos tan largos entre cada version que se libera, y la inevitable desmoralizacion cuando 
estas versiones, largamente esperadas, no resultan perfectas. 

En el enfoque de programacion estilo bazar, por otro lado, se asume que los errores son 
fenomenos relativamente evidentes o, por lo menos, que pueden volverse relativamente 
evidentes cuando se exhiben a miles de entusiastas desarrolladores asistentes que colaboran al 
parejo sobre cada una de las versiones. En consecuencia, se libera con frecuencia para poder 
obtener una mayor cantidad de correcciones, logrando como efecto colateral benefico el perder 
menos cuando un eventual obstaculo se atraviesa. 

Y eso es todo. Con eso basta. Si la Ley de Linus fuera falsa, entonces cualquier sistema 
suficientemente complejo como el kernel de Linux, que esta siendo manipulado por tantos, 
deberia haberse colapsado en un punto bajo el peso de ciertas 

interacciones imprevistas y errores "muy profundos" inadvertidos. Pero si es cierta, bastaria 
para explicar la relativa ausencia de errores en el codigo de Linux. 

Despues de todo, esto no debf parecernos tan sorpresivo. Hace algunos anos los sociologos 
descubrieron que la opinion promedio de un numero grande de observadores igualmente 
expertos (o igualmente ignorantes) es mas confiable de predecir que la de uno de los 
observadores seleccionado al azar. A esto se le conoce como el efecto Delphi. Al parecer, lo que 
Linus ha demostrado es que esto tambien es valedero en el ambito de la depuracion de un 
sistema operativo: que el efecto Delphi puede abatir la complejidad implfcita en el desarrollo, 
incluso al nivel de la involucrada en el desarrollo del nucleo de un OS. 



Estoy en deuda con Jeff Dutky, quien me sugirio que la Ley de Linus puede replantearse 
diciendo que "la depuracion puede hacerse en paralelo". Jeff senala que a pesar de que la 
depuracion requiere que los participantes se comuniquen con un programador que coordina el 
trabajo, no demana ninguna coordination significativa entre ellos. Por lo tanto, no cae victima 
de la asombrosa complejidad cuadratica y los 

costos de maniobra que ocasionan que la incorporation de desarrolladores resulte problematica. 

En la practica, la perdida teorica de eficiencia debido a la duplicacion del trabajo por parte de 
los programadores casi nunca es un tema que revista importancia en el mundo Linux. Un efecto 
de la "polftica de liberar rapido y a menudo" es que esta clase de duplicidades se minimizan al 
propagarse las correcciones rapidamente. 

Brooks hizo una observation relacionada con la de Jeff: "El costo total del mantenimiento de un 
programa muy usado es tipicamente alrededor del 40 por ciento o mas del costo del desarrollo. 
Sorpresivamente, este costo esta fuertemente influenciado por el numero de usuarios. Mas 
usuarios detectan una mayor cantidad de errores." (El subrayado es mio). 

Una mayor cantidad de usuarios detecta mas errores debido a que tienen diferentes maneras de 
evaluar el programa. Este efecto se incrementa cuando los usuarios son desarrolladores 
asaitentes. Cada uno enfoca la tarea de la caracterizacion de los errores con un bagaje conceptual 
e instrumentos analfticos distintos, desde un angulo diferente. El efecto Delphi parece funcionar 
precisamente debido a estas diferencias. En el contexto especifico de la depuracion, dichas 
diferencias tambien tienden a reducir la duplicacion del trabajo. 

Por lo tanto, el agregar mas beta-testers podria no contribuir a reducir la complejidad del "mas 
profundo" de los errores actuales, desde el punto de vista del desarrollador, pero aumenta la 
probabilidad de que la caja de herramientas de alguno de ellos se equipare al problema, de tal 
suerte que esa persona vea claramente el error. 

Linus tambien dobla sus apuestas. En el caso de que realmente existan errores serios, las 
versiones del kernel de Linux son enumeradas de tal manera que los usuarios potenciales puedan 
escoger la ultima version considerada como "estable" o ponerse al filo de la navaja y arriesgarse 
a los errores con tal de aprovechar las nuevas caracterfsticas. Esta tactica no ha sido 
formalmente imitada por la mayoria de los hackers de Linux, pero quiza debian hacerlo. El 
hecho de contar con ambas opciones, lo vuelve aun mas atractivo. 

5. ^Cuando una rosa no es rosa? 

Despues de estudiar la forma en que actuo Linus y haber formulado una teoria del por que tuvo 
exito, tome la decision consciente de probarla en mi nuevo proyecto (el cual, debo admitirlo, es 
mucho menos complejo y ambicioso). 

Lo primero que hice fue reorganizar y simplificar popclient. El trabajo de Carl Harris era muy 
bueno, pero exhibia una complejidad innecesaria, tipica de muchos de los programadores en C. 
El trataba el codigo como la parte central y las estructuras de datos como un apoyo para este. 
Como resultado, el codigo resulto muy elegante, pero el diseno de las estructuras de datos salio 
ad hoc y feo (por lo menos con respecto a los estandares exigentes de este viejo hacker de Lisp). 

Sin embargo, tenia otro motivo para reescribir, ademas de mejorar el diseno de la estructura de 
datos y el codigo: El proyecto debia evolucionar en algo que yo entendiera cabalmente. No es 



nada divertido ser el responsable de corregir los errores en un programa que no se entiende. 

Por lo tanto, durante el primer mes, o algo asi, simplemente fui siguiendo los pormenores del 
diseno basico de Carl. El primer cambio serio que realice fue agregar el soporte de IMAP. Lo 
hice reorganizando los administradores de protocolos en un administrador generico con tres 
tablas de metodos (para POP2, POP3 e IMAP). Este y algunos cambios anteriores muestran un 
principio general que es bueno que los programadores tengan en mente, especialmente los que 
programan en lenguajes tipo C y no hacen manejo de datos dinamicamente: 

9. Las estructuras de datos inteligentes y el codigo burdo funcionan mucho mejor que en el 
caso inverso. 

De nuevo, Fred Brooks, Capftulo 11: "Muestreme su codigo y esconda sus estructuras de datos, 
y continuare intrigado. Muestreme sus estructuras de datos y generalmente no necesitare ver su 
codigo; resultara evidente." 

En realidad, el hablaba de "diagramas de flujo" y "tablas". Pero, con treinta anos de cambios 
terminologicos y culturales, resulta practicamente la misma idea. 

En este momento (a principios de septiembre de 1996, aproximadamente seis semanas despues 
de haber comenzado) empece a pensar que un cambio de nombre podria ser apropiado. Despues 
de todo, ya no se trataba de un simple cliente POP. Pero todavia vacile, debido a que no habia 
nada nuevo y genuinamente mio en el diseno. Mi version del popclient tenia aun que desarrollar 
una identidad propia. 

Esto cambio radicalmente cuando fetchmail aprendio a remitir el correo recibido al puerto 
SMTP. Volvere a este punto en un momento. Primero quiero decir lo siguiente: yo afirme 
anteriormente que decidi utilizar este proyecto para probar mi teoria sobre la correcion del estilo 
Linus Torvalds. «<,C6mo lo hice? (podrfan ustedes preguntar muy bien). Fue de la siguiente 
manera: 

1. Liberaba rapido y a menudo (casi nunca deje de hacerlo en menos de diez dias; durante 
los perfodos de desarrollo intenso, una vez diaria). 

2. Ampliaba mi lista de analistas de versiones beta, incorporando a todo el que me 
contactara para saber sobre fetchmail. 

3. Efectuaba anuncios espectaculares a esta lista cada vez que liberaba una nueva version, 
estimulando a la gente a participar. 

4. Y escuchaba a mis analistas asistentes, consultandolos decisiones referentes al diseno y 
tomandolos en cuenta cuando me mandaban sus mejoras y la consecuente retroalimentacion. 

La recompensa por estas simples medidas fue inmediata. Desde el principio del proyecto obtuve 
reportes de errores de calidad, frecuentemente con buenas soluciones anexas, que envidiarfan la 
mayoria de los desarrolladores. Obtuve critica constructiva, mensajes de admiradores e 
inteligentes sugerencias. Lo que lleva a la siguiente leccion: 

10. Si usted trata a sus analistas (beta— testers) como sifueran su recurso mas valioso, ellos le 
responderdn convirtiendose en su recurso mas valioso. 

Una medida interesante del exito de fetchmail fue el tamano de la lista de analistas beta del 



proyecto, los amigos de fetchmail. Cuando escribi esto, tenia 249 miembros, y se sumaban entre 
dos y tres semanalmente. 

Revisandola hoy, finales de mayo de 1997, la lista ha comenzando a perder miembros debido a 
una razon sumamente interesante. jVarias personas me han pedido que los de de baja debido a 
que el fetchmail les esta funcionando tan bien que ya no necesitan ver todo el trafico de de la 
lista! A lo mejor esto es parte del ciclo vital normal de un proyecto maduro realizado por el 
metodo de construction estilo bazar. 

6. popclient se convierte en fetchmail 

El momento crucial para el proyecto fue cuando Harry Hochheiser me mando su codigo fuente 
para incorporar la remision del correo recibido a la maquina cliente a traves del puerto SMTP. 
Comprendi casi inmediatamente que una implementation adecuada de esta caracterfstica iba a 
dejar a todos los demas metodos a un paso de ser obsoletos. 

Durante muchas semanas habia estado perfeccionando fetchmail, agregandole caracterfsticas, a 
pesar de que sentia que el diseno de la interfaz era util pero algo burdo, poco elegante y con 
demasiadas opciones insignificantes colgando fuera de lugar. La facilidad de vaciar el correo 
recibido a un archivo-buzon de correos o la salida estandar me incomodaba de cierta manera, 
pero no alcanzaba a comprender por que. 

Lo que adverti cuando me puse a pensar sobre la expedition del correo por el SMTP fue que el 
popclient estaba intentando hacer demasiadas cosas juntas. Habia sido disenado para funcionar 
al mismo tiempo como un agente de transporte (MTA) y un agente de entrega (MDA). Con la 
remision del correo por el SMTP podria abandonar la funcion de MDA y centrarme solamente 
en la de MTA, mandando el correo a otros 

programas para su entrega local, justo como lo hace sendmail. 

«<,Por que sufrir con toda la complejidad que encierra ya sea configurar el agente de entrega o 
realizar un bloqueo y luego un anadido al final del archivo-buzon de correos, cuando el puerto 
25 esta casi garantizado casi en toda plataforma con soporte TCP/IP? Especialmente cuando esto 
significa que el correo obtenido de esta manera tiene garantizado verse como un correo que ha 
sido transferido de manera normal, por el SMTP, que es lo que realmente queremos. 

De aqui se extraen varias lecciones. Primero, la idea de enviar por el puerto SMTP fue la mayor 
recompensa individual que obtuve al tratar de emular conscientemente los metodos de Linus. Un 
usuario me proporciono una fabulosa idea, y lo unico que restaba era comprender sus 
implicaciones. 

11. Lo mas grande, despues de tener buenas ideas, es reconocer las buenas ideas de sus 
usuarios. Esto ultimo es a veces lo mejor. 

Lo que resulta muy interesante es que usted rapidamente encontrara que cuando esta 
absolutamente convencido y seguro de lo que le debe a los demas, entonces el mundo lo tratara 
como si usted hubiera realizado cada parte de la invention por si mismo, y esto le hara apreciar 
con modestia su ingenio natural. ; Todos podemos ver lo bien que funciono esto para el propio 
Linus! 

(Cuando leia este documento en la Conferencia de Perl de agosto de 1997, Larry Wall estaba en 
la fila del frente. Cuando llegue a lo que acabo de decir, Larry dijo con voz alta: "jAnda, di eso, 



diselos, hermano!." Todos los presentes rieron porque 
sabfan que eso tambien le habia funcionado muy bien al inventor de Perl) 

Y a unas cuantas semanas de haber echado a andar el proyecto con el mismo espfritu, comence 
a recibir adulaciones similares, no solo de parte de mis usuarios, sino de otra gente que se habia 
enterado por terceras personas. He puesto a buen recaudo parte de ese correo. Lo volveria a leer 
en alguna ocasion, si es que me llego a preguntar si mi vida ha valido la pena :-). 

Pero hay otras dos lecciones mas fundamentales, que no tienen que ver con las polfticas, que 
son generales para todos los tipos de diseno: 

12. Frecuentemente, las soluciones mas innovadoras y espectaculares provienen de 
comprender que la conception del problema era erronea. 

Habia estado intentando resolver el problema equivocado al continuar desarrollando el 
popclient como un agente de entrega y de transporte combinados, con toda clase de modos 
medio raros de entrega local. El diseno de fetchmail requeria ser repensado de arriba abajo como 
un agente de transporte puro, como eslabon, si se habia de SMTP, de la rata normal que sigue el 
correo en Internet. 

Cuando usted se topa con un muro durante el desarrollo -cuando la encuentra diffcil como para 
pensar mas alia de la correction que sigue- es, a menudo, la hora de preguntarse no si usted 
realmente tiene la respuesta correcta, sino si se esta planteando la pregunta correcta. Quizas el 
problema requiere ser replanteado. 

Bien, yo ya habia replanteado mi problema. Evidentemente, lo que tenia que hacer ahora era (1) 
programar el soporte de envio por SMTP en el controlador generico, (2) hacerlo el modo por 
omision, y (3) eliminar eventualmente todas las demas modalidades de entrega, especialmente 
las de envio a un archivo-buzon y la de vaciado a la salida estandar. 

Estuve, durante algun tiempo, titubeando en dar el paso 3; temiendo trastornar a los viejos 
usuarios de poclient, quienes dependfan de estos mecanismos alternativos de entrega. En teoria, 
ellos podfan cambiar inmediatamente a archivos .forward, o sus equivalentes en otro esquema 
que no fuera sendmail, para obtener los mismos resultados. Pero, en la practica, la transition 
podria complicarse demasiado. 

Cuando por fin lo hice, empero, los beneficios fueron inmensos. Las partes mas intrincadas del 
codigo del controlador desaparecieron. La configuration se volvio radicalmente mas simple: al 
no tratar con el MDA del sistema y con el archivo-buzon del usuario, ya no habia que 
preocuparse de que el sistema operativo soportara bloqueo de archivos. 

Asimismo, el unico riesgo de extraviar correo tambien se habia desvanecido. Antes, si usted 
especificaba el envio a un archivo-buzon y el disco estaba lleno, entonces el correo se perdia 
irremediablemente. Esto no pasa con el envio via SMTP debido a que el SMTP del receptor no 
devolvera un OK mientras el mensaje no haya sido entregado con exito, o al menos haya sido 
mandado a la cola para su entrega ulterior. 

Ademas, el desempeno mejoro mucho (aunque uno no lo notara en la primera corrida). Otro 
beneficio nada despreciable fue la simplification de la pagina del manual. 

Mas adelante hubo que agregar la entrega a un agente local especificado por el usuario con el 



fin de manejar algunas situaciones oscuras involucradas con la asignacion dinamica de 
direcciones en SLIP. Sin embargo, encontre una forma mucho mas simple de hacerlo. 

<<,Cual era la moraleja? No hay que vacilar en desechar alguna caracterfstica superflua si puede 
hacerlo sin perdida de efectividad. Antoine de Saint-Exupery (un aviador y disenador de 
aviones, cuando no se dedicaba a escribir libros clasicos para ninos) afirmo que 

13. "La perfection (en diseno) se alcanza no cuando ya no hay nada que agregar, sino cuando 
ya no hay algo que quitar. " 

Cuando el codigo va mejorando y se va simplificando, es cuando sabe que esta en lo correcto. 
Asi, en este proceso, el diseno de fetchmail adquirio una identidad propia, diferente de su 
ancestro, el popclient. 

Habia llegado la hora de cambiar de nombre. El nuevo diseno parecia mas un doble del 
Sendmail que el viejo popclient; ambos eran MTAs, agentes de transporte, pero mientras que el 
Sendmail empuja y luego entrega, el nuevo popclient jala y despues entrega. Asi que, despues de 
dos arduos meses, lo bautice de nuevo con el nombre de fetchmail. 

7. El crecimiento de fetchmail 

Alii me encontraba con un bonito e innovador diseno, un programa que sabia funcionaba bien 
porque lo utilizaba diariamente, y me enteraba por la lista beta, que era muy activa. Esta 
gradualmente me hizo ver que ya no estaba involucrado en un hackeado personal trivial, que 
podia resultar util para unas cuantas personas mas. Tenia en mis manos un programa que 
cualquier hacker con una caja UNIX y una conexion SLIP/PPP realmente necesita. 

Con el metodo de expedicion por SMTP se puso adelante de la competencia, lo suficiente como 
para poder convertirse en un "maton profesional", uno de esos programas clasicos que ocupa tan 
bien su lugar que las otras alternativas no solo son descartadas, sino olvidadas. 

Pienso que uno realmente no podria imaginar o planear un resultado como este. Usted tiene que 
meterse a manejar conceptos de diseno tan poderosos que posteriormente los resultados parezcan 
inevitables, naturales, o incluso predestinados. La unica manera de hacerse de estas ideas es 
jugar con un monton de ideas; o tener una vision de la ingenieria suficiente para poder llevar las 
buenas ideas de otras personas mas alia de lo que sus propios autores originales pensaban que 
podfan llegar. 

Andrew Tanenbaum tuvo una buena idea original, con la construction de un UNIX nativo 
simple para 386, que sirviera como herramienta de ensenanza. Linus Torvalds llevo el concepto 
de Minix mas alia de lo que Andrew imagino que pudiera llegar, y se transformo en algo 
maravilloso. De la misma manera (aunque en una escala menor), tome algunas ideas de Carl 
Harris y Harry Hochheiser y las impulse fuertemente. Ninguno de nosotros era "original" en el 
sentido romantico de la idea que la gente tiene de un genio. Pero, la mayor parte del desarrollo 
de la ciencia, la ingenieria y el software no se debe a un genio original, sino a la mitologfa del 
hacker por el contrario. 

Los resultados fueron siempre un tanto complicados: de hecho, jjusto el tipo de reto para el que 
vive un hacker! Y esto implicaba que tenia que fijar aun mas alto mis propios estandares. Para 
hacer que el fetchmail fuese tan bueno como ahora veia que podia ser, tenia que escribir no solo 
para satisfacer mis propias necesidades, sino tambien incluir y dar el soporte a otros que 



estuvieran fuera de mi orbita. Y esto lo tenia que hacer manteniendo el programa sencillo y 
robusto. 

La primera caracterfstica mas importante y contundente que escribi despues de hacer eso fue el 
soporte para recabado multiple, esto es, la capacidad de recoger el correo de los buzones que 
habfan acumulado todo el correo de un grupo de usuarios, y luego trasladar cada mensaje al 
recipiente individual del respectivo destinatario. 

Decidi agregarle el soporte de recabado multiple debido en parte a que algunos usuarios lo 
reclamaban, pero sobre todo porque evidenciaria los errores de un codigo de recabado 
individual, al forzarme a abordar el direccionamiento con generalidad. Tal como ocurrio. Poner 
el RFC822 a que funcionara correctamente me tomo bastante tiempo, no solo porque cada uno 
de las partes que lo componen son diffciles, sino porque involucraban un monton de detalles 
confusos e interdependientes entre si. 

Asi, pues, el direccionamiento del recabado multiple se volvio una excelente decision de diseno. 
De esta forma supe que: 

14 Toda herramienta es util empledndose de la forma prevista, pero una *gran* herramienta es 
la que se presta a ser utilizada de la manera menos esperada. 

El uso inesperado del recabado multiple del fetchmail fue el trabajar listas de correo con la lista 
guardada, y realizar la expansion del alias en el lado del cliente de la conexion SLIP/PPP. Esto 
significa que alguien que cuenta con una computadora y una cuenta de ISP puede manejar una 
lista de correos sin que tenga que continuar entrando a los archivos del alias del ISP. 

Otro cambio importante reclamado por mis auxiliares beta era el soporte para la operation 
MIME de 8 bits. Esto se podia obtener facilmente, ya que habia tenido cuidado de mantener el 
codigo de 8 bits limpio. No es que yo me hubiera anticipado a la exigencia de esta caracterfstica, 
sino que obedecia a otra regla: 

75. Cudndo se escribe software para una puerta de enlace de cualquier tipo, hay que tomar la 
precaucion de alterar el flujo de datos lo menos posible, y j*nunca* eliminar informacion a 
menos que los receptores obliguen a hacerlo! 

Si no hubiera obedecido esta regla, entonces el soporte MIME de 8 bits habria resultado diffcil 
y lleno de errores. Asi las cosas, todo lo que tuve que hacer fue leer el RFC 1652 y agregar algo 
de logica trivial en la generation de encabezados. 

Algunos usuarios europeos me presionaron para que introdujera una option que limitase el 
numero de mensajes acarreados por sesion (de manera tal que pudieran controlar los costos de 
sus redes telefonicas caras). Me opuse a dicho cambio durante mucho tiempo, y aun no estoy 
totalmente conforme con el. Pero si usted escribe para el mundo, debe escuchar a sus clientes: 
esto no debe cambiar en nada tan solo porque no le estan dando dinero. 

8. Algunas lecciones mas extraidas de fetchmail 

Antes de volver a los temas generales de ingenieria de software, hay que ponderar otras dos 
lecciones especificas sacadas de la experiencia de fetchmail. 

La sintaxis de los archivos re incluyen palabras clave opcionales "de ruido" que son ignoradas 



totalmente por el analizador de sintaxis. La sintaxis tipo ingles que estas permiten es 
considerablemente mas legible que la secuencia de pares palabra clave-valor tradicionales que 
usted obtiene cuando quita esas palabras clave opcionales. 

Estas comenzaron como un experimento de madrugada, cuando note que muchas de las 
declaraciones de los archivos re se asemejaban un poco a un minilenguaje imperativo. (Esta 
tambien fue la razon por la cual cambie la palabra clave original del popclient de "servidor" a 
"poll"). 

Me parecia en ese entonces que el convertir ese minilenguaje imperativo mas tipo ingles lo 
podia hacer mas facil de usar. Ahora, a pesar de que soy un partidario convencido de la escuela 
de diseno "hagalo un lenguaje", ejemplificada en Emacs, HTML y muchas bases de datos, no 
soy normalmente un fanatico de la sintaxis estilo ingles. 

Los programadores han tendido a favorecer tradicionalmente la sintaxis de control, debido a 
que es muy precisa, compacta y no tienen redundancia alguna. Esto es una herencia cultural de 
la epoca en que los recursos de compute eran muy caros, por lo que la etapa de analisis tenia que 
ser la mas sencilla y economica posible. El ingles, con un 50% de redundancia, parecia ser un 
modelo muy inapropiado en ese entonces. 

Esta no es la razon por la cual yo dudo de la sintaxis tipo ingles; y solo lo menciono aqui para 
demolerlo. Con los ciclos baratos, la fluidez no debe ser un fin por si misma. Ahora es mas 
importante para un lenguaje el ser conveniente para los humanos que ser economico en terminos 
de recursos computacionales. 

Sin embargo, hay razones suficientes para andar con cuidado. Una es el costo de la complejidad 
de la etapa de analisis: nadie quiere incrementarlo a un punto tal que se vuelva una fuente 
importante de errores y confusion para el usuario. Otra radica en que al hacer una sintaxis del 
lenguaje tipo ingles se exige frecuentemente que se deforme considerablemente el "ingles" que 
habla, por lo que la semejanza superficial con un lenguaje natural es tan confusa como podria 
haberlo sido la sintaxis tradicional. (Usted puede ver mucho de esto en los 4GLs y en los 
lenguajes de busqueda en bancos de datos comerciales). 

La sintaxis de control de fetchmail parece esquivar estos problemas debido a que el dominio de 
su lenguaje es extremadamente restringido. Esta muy lejos de ser un lenguaje de amplio uso; las 
cosas que dice no son muy complicadas, por lo que hay pocas posibilidades de una confusion, al 
mo verse de un reducido subconjunto del ingles y el lenguaje de control real. Creo que se puede 
extraer una leccion mas general de esto: 

16. Cuando su lenguaje esta lejos de un Turing completo, entonces el azucar sintdctico puede 
ser su amigo. 

Otra leccion trata de la seguridad por obscuridad. Algunos usuarios de fetchmail me solicitaron 
cambiar el software para poder guardar las claves de acceso encriptadas en su archivo re, de 
manera tal que los crackers no pudieran verlos por pura casualidad. 

No lo hice debido a que esto practicamente no proporcionaria ninguna protection adicional. 
Cualquiera que adquiera los permisos necesarios para leer el archivo re respectivo seria de todos 
modos capaz de correr el fetchmail; y si por su password fuera, podria sacar el decodificador 
necesario del mismo codigo del fetchmail para obtenerlo. 



Todo lo que la encriptacion de passwords en el archivo .fetchmailrc podria haber conseguido 
era una falso sensacion de seguridad para la gente que no esta muy metida en este medio. La 
regla general es la siguiente: 

1 7. Un sistema de seguridad es tan seguro como secreto. Cuidese de los secretos a medias. 

9. Condiciones necesarias para el estilo del bazar 

Los primeros que leyeron este documento, asi como sus primeras versiones inacabadas que se 
hicieron publicas, preguntaban constantemente sobre los requisitos necesarios para un desarrollo 
exitoso dentro del modelo del bazar, incluyendo tanto la calificacion del lider del proyecto como 
la del estado del codigo cuando uno va a hacerlo publico y a comenzar a construir una 
comunidad de co-desarrolladores. 

Esta claro que uno no puede partir de cero en el estilo bazar. Con el, uno puede probar, buscar 
errores, poner a punto y mejorar algo, pero seria muy diffcil originar un proyecto en un modo 
semejante al bazar. Linus no lo intento de esta manera. Yo tampoco lo hice asi. Nuestra naciente 
comunidad de desarrolladores necesita algo que ya corra para jugar. 

Cuando uno comienza la construction del edificio comunal, lo que debe ser capaz de hacer es 
presentar una promesa plausible. El programa no necesita ser particularmente bueno. Puede ser 
burdo, tener muchos errores, estar incompleto y pobremente documentado. Pero en lo que no se 
puede fallar es en convencer a los co-desarrolladores potenciales de que el programa puede 
evolucionar hacia algo elegante en el future 

Linux y fetchmail se hicieron publicos con disenos basicos fuertes y atractivos. Mucha gente 
piensa que el modelo del bazar tal como lo he presentado, ha considerado correctamente esto 
como critico, y luego ha saltado de aqui a la conclusion de que es indispensable que el lider del 
proyecto tenga un mayor nivel de intuition para el diseno y mucha capacidad. 

Sin embargo, Linus obtuvo su diseno a partir de UNIX. Yo inicialmente consegui el mio del 
antiguo popmail (a pesar de que cambiaria mucho posteriormente, mucho mas, guardando las 
proporciones, de lo que lo ha hecho Linux). Entonces, ^tiene que poseer realmente un talento 
extraordinario el lider-coordinador en el modelo del bazar, o la puede ir pasando con tan solo 
coordinar el talento de otros para el diseno? 

Creo que no es critico que el coordinador sea capaz de originar disenos de calidad excepcional, 
pero lo que si es absolutamente esencial es que el (o ella) sea capaz de reconocer las buenas 
ideas sobre diseno de los demas. 

Tanto el proyecto de Linux como el de fetchmail dan evidencias de esto. A pesar de que Linus 
no es un disenador original espectacular (como lo discutimos anteriormente), ha mostrado tener 
una poderosa habilidad para reconocer un buen diseno e integrarlo al kernel de Linux. Ya he 
descrito como la idea de diseno de mayor envergadura para el fetchmail (reenvio por SMTP) 
pro vino de otro. 

Los primeros lectores de este articulo me halagaron al sugerir que soy propenso a subestimar la 
originalidad en el diseno en los proyectos del bazar, debido a que la tengo en buena medida, y 
por lo tanto, la tomo por sentada. Puede ser verdad en parte; el diseno es ciertamente mi fuerte 
(comparado con la programacion o la depuration). 



Pero el problema de ser listo y original en el diseno de software se tiende a convertir en habito: 
uno hace las cosas como por reflejo, de manera tal que parezcan elegantes y complicadas, 
cuando deberia mantenerlas simples y robustas. Ya he sufrido tropiezos en proyectos debido a 
esta equivocation, pero me las ingenie para no sucediera lo mismo con fetchmail. 

Asi, pues, considero que el proyecto del fetchmail tuvo exito en parte debido a que contuve mi 
propension a ser astuto; este es un argumento que va (por lo menos) contra la originalidad en el 
diseno como algo esencial para que los proyectos del bazar sean exitosos. Consideremos de 
nuevo Linux. Supongase que Linus Torvalds hubiera estado tratando de desechar innovaciones 
fundamentales en el diseno del sistema operativo durante la etapa de desarrollo; ^podria acaso 
ser tan estable y exitoso como el kernel que tenemos hoy en realidad? 

Por supuesto, se necesita un cierto nivel minimo de habilidad para el diseno y la escritura de 
programas, pero es de esperar que cualquiera que quiera seriamente lanzar un esfuerzo al estilo 
del bazar ya este por encima de este nivel. El mercado interno de la comunidad del software 
libre, por reputation, ejerce una presion sutil sobre la gente para que no inicie esfuerzos de 
desarrollo que no sea capaz de mantener. Hasta ahora, esto parece estar funcionando bastante 
bien. 

Existe otro tipo de habilidad que no esta asociada normalmente con el desarrollo del software, 
la cual yo considero que es igual de importante para los proyectos del bazar, y a veces hasta 
mas, como el ingenio en el diseno. Un coordinador o lider de proyecto estilo bazar debe tener 
don de gentes y una buena capacidad de comunicacion. 

Esto podria parecer obvio. Para poder construir una comunidad de desarrollo se necesita atraer 
gente, interesarla en lo que se esta haciendo y mantenerla a gusto con el trabajo que se esta 
desarrollando. El entusiasmo tecnico constituye una buena parte para poder lograr esto, pero esta 
muy lejos de ser definitivo. Ademas, es importante la personalidad que uno proyecta. 

No es una coincidencia que Linus sea un tipo que hace que la gente lo aprecie y desee ayudarle. 
Tampoco es una coincidencia que yo sea un extrovertido incansable que disfruta de trabajar con 
una muchedumbre, y tenga un poco de porte e instintos de comico improvisado. Para hacer que 
el modelo bazar funcione, ayuda mucho tener al menos un poco de capacidad para las relaciones 
sociales. 

10. El contexto social del software libre 

Bien se ha dicho: las mejores hackeadas comienzan como soluciones personales a los problemas 
cotidianos del autor, y se se vuelven populares debido a que el problema comun para un buen 
grupo de usuarios. Esto nos hace regresar al tema de la regla 1, que quiza puede replantearse de 
una manera mas util: 

18. Para resolver un problema interesante, comience por encontrar un problema que le resulte 
interesante. 

Asi ocurrio con Carl Harris y el antiguo popclient, y asi sucede conmigo y fetchmail. Esto, sin 
embargo, se ha entendido desde hace mucho. El punto interesante, el punto que las historias de 
Linux y fetchmail nos piden enfocar, esta en la siguiente etapa, en la de la evolution del 
software en presencia de una amplia y activa comunidad de usuarios y co-desarrolladores. 

En The Mythical Man-Month, Fred Brooks observo que el tiempo del programador no es 



fungible; que el agregar desarrolladores a un proyecto maduro de software lo vuelve tardfo. 
Expuso que la complejidad y los costos de comunicacion de un proyecto aumentan como el 
cuadrado del numero de desarrolladores, mientras que el trabajo crece solo linealmente. A este 
planteamiento se le conoce como la Ley de Brooks, y es generalmente aceptado como algo 
cierto. Pero si la Ley de Brooks fuese general, entonces Linux seria imposible. 

Unos anos despues, el clasico de Gerald Weinberg La Psicologfa de la Programacion de 
Computadoras plantea, visto en retro spectiva, una correction esencial a Brooks. En su discusion 
de la "programacion sin ego", Weinberg senala que en los lugares donde los desarrolladores no 
tienen propiedad sobre su codigo, y estimulan a otras personas a buscar errores y posibles 
mejoras, son los lugares donde el avance es dramaticamente mas rapido que en cualquier otro 
lado. 

La terminologia empleada por Weinberg ha evitado quiza que su analisis gane la aceptacion que 
merece: uno tiene que sonreir al ofr que los hackers de Internet no tienen ego. Creo, no obstante, 
que su argumentation parece mas valida ahora que nunca. 

La historia de UNIX debio habernos preparado para lo que hemos aprendido de Linux (y lo que 
he verificado experimentalmente en una escala mas reducida al copiar 

deliberadamente los metodos de Linus). Esto es, mientras que la creation de programas sigue 
siendo esencialmente una actividad solitaria, los desarrollos realmente grandes surgen de la 
atencion y la capacidad de pensamiento de comunidades enteras. El desarrollador que usa 
solamente su cerebro sobre un proyecto cerrado esta quedando detras del que sabe como crear en 
un contexto abierto y evolutivo en el que la busqueda de errores y las mejoras son realizadas por 
cientos de personas. 

Pero el mundo tradicional de UNIX no pudo llevar este enfoque hasta sus ultimas 
consecuencias debido a varios factores. Uno era las limitaciones legales producidas por varias 
licencias, secretos e intereses comerciales. Otra (en retro spectiva) era que la Internet no estaba 
todavia madura para lograrlo. 

Antes de que Internet fuera tan accesible, habia comunidades geograficamente compactas en las 
cuales la cultura estimulaba la "programacion sin ego" de Weinberg, y el desarrollador podia 
atraer facilmente a muchos desarrolladores y usuarios capacitados. El Bell Labs, el MIT Al Lab, 
la Universidad de California en Berkeley son lugares donde se originaron innovaciones que son 
legendarias y aun poderosas. 

Linux fue el primer proyecto de un esfuerzo consciente y exitoso de usar el mundo entero como 
un nido de talento. No creo que sea coincidencia que el perfodo de gestation de Linux haya 
coincidido con el nacimiento de la World Wide Web, y que Linux haya dejado su infancia 
durante el mismo perfodo, en 1993-1994, en que se vio el despegue de la industria ISP y la 
explosion del interes masivo por la Internet. Linus fue el primero que aprendio a jugar con las 
nuevas reglas que esa Internet penetrante hace posibles. 

A pesar de que la Internet barata es una condicion necesaria para que evolucionara el modelo de 
Linux, no creo que sea en si misma una condicion suficiente. Otros factores vitales fueron el 
desarrollo de un estilo de liderazgo y el arraigo de habitos cooperativos, que permiten a los 
programadores atraer mas co-desarrolladores y obtener el maximo provecho del medio. 

Pero, «<,que es el estilo de liderazgo y que estos habitos? No pueden estar basados en relaciones 
de poder, y aunque lo fueran, el liderazgo por coercion no produciria los resultados que estamos 



viendo. Weinberg cita un pasaje de la autobiograffa del anarquista ruso del siglo XIX Kropotkin 
Memorias de un Revolucionario, que esta muy acorde con este tenia: 

"Habiendo sido criado en una familia que tenia siervos, me incorpore a la vida activa, como 
todos los jovenes de mi epoca, con una gran confianza en la necesidad de mandar, ordenar, 
reganar, castigar y cosas semej antes. Pero cuando, en una etapa temprana, tuve que manejar 
empresas serias y tratar con hombres libres, y cuando cada error podria acarrear serias 
consecuencias, yo comence a apreciar la diferencia entre actuar con base en el principio de 
orden y disciplina y actuar con base en el principio del entendimiento. El primero funciona 
admirablemente en un desfile militar, pero no sirve cuando esta involucrada la vida real y el 
objetivo solo puede lograrse mediante el esfuerzo serio de muchas voluntades convergentes." 

El "esfuerzo serio de muchas voluntades convergentes" es precisamente lo que todo proyecto 
estilo Linux requiere; mientras que el "principio de orden y disciplina" es efectivamente 
imposible de aplicar a los voluntarios del paraiso anarquista que llamamos Internet. Para poder 
trabajar y competir de manera efectiva, los hackers que quieran encabezar proyectos de 
colaboracion deben aprender a reclutar y entusiasmar a las comunidades de interes de un modo 
vagamente sugerido por el "principio de entendimiento" de Kropotkin. Deben aprender a usar la 
Ley de Linus. 

Anteriormente me referi al efecto Delphi como una posible explication de la Ley de Linus. 
Pero existen analogfas mas fuertes con sistemas adaptivos en biologfa y economia que se 
sugieren irresistiblemente. El mundo de Linux se comporta en muchos aspectos como el libre 
mercado o un sistema ecologico, donde un grupo de agentes individualistas buscan maximizar la 
utilidad en la que los procesos generan un orden espontaneo autocorrectivo mas desarrollado y 
eficiente que lo que podria lograr cualquier tipo de planeacion centralizada. Aqui, entonces, es el 
lugar para ver el "principio del entendimiento". 

La "funcion utilidad" que los hackers de Linux estan maximizando no es economica en el 
sentido clasico, sino algo intangible como la satisfaccion de su ego y su reputacion entre otros 
hackers. (Uno podria hablar de su "motivacion altruista", pero ignorarfamos el hecho de que el 
altruismo en si mismo es una forma de satisfaccion del ego para el altruista). Los grupos 
voluntarios que funcionan de esta manera no son escasos realmente; uno en el que he participado 
es el de los aficionados a la ciencia fiction, que a diferencia del mundo de los hackers, reconoce 
explfcitamente el "egoboo" (el realce de la reputacion de uno entre los demas) como la 
motivacion basica que esta detras de la actividad de los voluntarios. 

Linus, al ponerse exitosamente como vigfa de un proyecto en el que el desarrollo es realizado 
por otros, y al alimentar el interes en el hasta que se hizo autosustentable, ha mostrado el largo 
alcance del "principio de entendimiento mutuo" de Kropotkin. Este enfoque cuasieconomico del 
mundo de Linux nos permite ver cual es la funcion de tal entendimiento. 

Podemos ver al metodo de Linus como la forma de crear un mercado eficiente en el "egoboo", 
que liga, lo mas firme posible, el egofsmo de los hackers individuales a objetivos diffciles que 
solo se pueden lograr con la cooperation sostenida. Con el proyecto de fetchmail he demostrado 
(en una escala mucho menor, claro) que sus metodos pueden copiarse con buenos resultados. 
Posiblemente, lo mio fue realizado de una forma un poco mas consciente y sistematica que la de 
el. 

Muchas personas (especialmente aquellas que desconffan polfticamente del libre mercado) 
podrfan esperar que una cultura de individuos egofstas que se dirigen solos sea fragmentaria, 



territorial, clandestina y hostil. Pero esta idea es claramente refutada, por (por poner un ejemplo) 
la asombrosa variedad, calidad y profundidad de la documentation de Linux. Se da por un hecho 
que los programadores odian la documentation: ^como entonces los hackers de Linux generan 
tanta? Evidentemente, el libre mercado en egoboo de Linux funciona mejor para producir tal 
virtuosismo, que los epartamentos de edition, masivamente subsidiados, de los productores 
comerciales de software. 

Tanto el proyecto de fetchmail como el del kernel de Linux han demostrado que con el estimulo 
apropiado al ego de otros hackers, un desarrollador/coordinador fuerte puede usar la Internet 
para aprovechar los beneficios de contar con un gran numero de co-desarrolladores, sin que se 
corra el peligro de desbocar el proyecto en un autentico relajo. Por lo tanto, a la Ley de Brooks 
yo le contrapongo lo siguiente: 

19. Si el coordinador de desarrollo tiene un medio al menos tan bueno como lo es Internet, y 
sabe dirigir sin coercion, muchas cabezas serdn, inevitablemente, mejor que una. 

Pienso que el futuro del software libre sera cada vez mas de la gente que sabe como jugar el 
juego de Linus, la gente que deja atras la catedral y abraza el bazar. Esto no quiere decir que la 
vision y la brillantez individuales ya no importen; al contrario, creo que en la vanguardia del 
software libre estaran quienes comiencen con vision y brillantez individual, y luego las 
enriquezcan construyendo positivamente comunidades voluntarias de interes. 

A lo mejor este no solo es el futuro del software libre. Ningun desarrollador comercial seria 
capaz de reunir el talento que la comunidad de Linux es capaz de invertir en un problema. jMuy 
pocos podrfan pagar tan solo la contratacion de las mas de doscientas personas que han 
contribuido al fetchmail! 

Es posible que a largo plazo triunfe la cultura del software libre, no porque la cooperation es 
moralmente correcta o porque la "apropiacion" del software es moralmente incorrecta 
(suponiendo que se crea realmente en esto ultimo, lo cual no es cierto ni para Linus ni para mi), 
sino simplemente por que el mundo comercial no puede ganar una carrera de armamentos 
evolutiva a las comunidades de software libre, que pueden poner mayores ordenes de magnitud 
de tiempo calificado en un problema que cualquier companfa. 

11. Reconocimientos 

Este articulo fue mejorado gracias a las conversaciones con un gran numero de personas que me 
ayudaron a encontrar los errores. En especial, agradezco a Jeff Dutky, quien sugirio el 
planteamiento de que "la busqueda de errores pude hacerse en 

paralelo" y ayudo a ampliar el analisis respective Tambien agradezco a Nancy Lebovitz por su 
sugerencia de emular a Weinberg al imitar a Kropotkin. Tambien recibi criticas perspicaces de 
Joan Eslinger y de Marty Franz de la lista de Tecnicos Generales. Paul Egger me hizo ver el 
conflicto entre el GPL y el modelo de bazar. Estoy agradecido con los integrantes de PLUG, el 
Grupo de Usuarios de Linux de Filadelfia, por convertirse en el primer publico para la primera 
version de este articulo. Finalmente, los comentarios de Linus Torvalds fueron de mucha ayuda, 
y su apoyo initial fue muy estimulante. 

12. Otras lecturas 

He citado varias partes del clasico de Frederick P. Brooks The Mythical Man-Month debido a 
que en muchos aspectos, todavia se tienen que mejorar sus puntos de vista. Yo recomiendo con 



carino la edicion del 25 aniversario de la Addison- Wesley (ISBN 0-201-83595-9), que viene 
junto a su articulo titulado Ninguna Bala de Plata. 

La nueva edicion trae una invaluable retrospectiva de veinte anos, en la que Brooks admite 
francamente ciertas criticas al texto original que no pudieron mantenerse con el tiempo. Lei por 
primera vez la retrospectiva despues de que estaba esencialmente terminado este articulo, y jme 
sorprendi al encontrar que Brooks le atribuye a Microsoft practicas semejantes a las del bazar! 

La Psicologfa de la Programacion de Computadoras de Gerald P. Wienberg (Nueva York, Van 
Nostrand Reinhold, 1971) introdujo el concepto infortunadamente denotado de "programacion 
sin ego". A pesar de que el estaba muy lejos de ser la primera persona en comprender la futilidad 
del "principio de orden" fue probablemente el primero en reconocer y argumentar el tema en 
relation con el desarrollo del software. 

Richard P. Gabriel, al analizar la cultura de UNIX anterior a la era de Linux, planteaba la 
superioridad de un primitivo modelo estilo bazar en un articulo de 1989: Lisp: Buenas Noticias, 
Malas Noticias y Como Ganar en Grande. Pese a estar atrasado en algunos aspectos, este ensayo 
es considerado correcto en algo por los admiradores de Lisp (entre quienes me incluyo). Uno de 
ellos me recordo que la section titulada Lo Peor es Mejor predice con gran exactitud a Linux. 

El trabajo de De Marco y Lister, Peopleware: Productive Projects and Teams (Nueva York; 
Dorset House, 1987; ISBN 0-932633-05-6) es una joya que ha sido subestimada; fue citada, 
para mi fortuna, por Fred Brooks en su retrospectiva. A pesar de que poco de lo que dicen los 
autores es directamente aplicable a las comunidades de software libre o de Linux, su vision 
sobre las condiciones necesarias para un trabajo creativo es aguda y muy recomendable para 
quien intente llevar algunas de las virtudes del modelo bazar a un contexto mas comercial. 

13. Epflogo: ;Netscape adopta el bazar! 

Es un extrano sentimiento el que se percibe cuando uno comprende que esta ayudando a escribir 
historia... 

El 22 de Enero de 1998, aproximadamente siete meses despues de que publique este articulo, 
Netscape Communications, Inc. anuncio planes para liberar la fuente del Netscape 
Communicator. No tenia idea alguna de que esto iba a suceder antes de la fecha de anuncio. 

Eric Hahn, Vicepresidente Ejecutivo y Director en Jefe de Tecnologfa en Netscape, me mando 
un correo electronico poco despues del anuncio, que dice textualmente: ' 'De parte de todos los 
que integran Netscape, quiero agradecerle por habernos ayudado a llegar hasta este punto, en 
primer lugar. Su pensamiento y sus escritos fueron inspiraciones fundamentales en nuestra 
decision." 

La siguiente semana, realice un viaje en avion a Silicon Valley como parte de la invitation para 
realizar una conferencia de todo un dia acerca de estrategia (el 4 de febrero de 1998) con 
algunos de sus tecnicos y ejecutivos de mayor nivel. Juntos, disenamos la estrategia de 
publication de la fuente de Netscape y la licencia, y realizamos algunos otros planes que 
esperamos que eventualmente tengan implicaciones positivas de largo alcance sobre la 
comunidad de software gratuito. En el momento que estoy escribiendo, es demasiado pronto 
para ser mas especifico, pero se van a ir publicando los detalles en las semanas por venir. 

Netscape esta a punto de proporcionarnos con una prueba a gran escala, en el mundo real, del 



modelo del bazar dentro del ambito empresarial. La cultura del software gratuito ahora enfrenta 
un peligro; si no funcionan las acciones de Netscape, entonces el concepto de software gratuito 
puede llegar a desacreditarse de tal manera que el mundo empresarial no lo abordara 
nuevamente sino hasta en una decada. 

Por otro lado, esto es tambien una oportunidad espectacular. La reaction inicial hacia este 
movimiento en Wall Street y en otros lados fue cautelosamente positiva. Nos estan 
proporcionando una oportunidad de demostrar que nosotros podemos hacerlo. Si Netscape 
recupera una parte significativa del mercado mediante este movimiento, puede desencadenar una 
revolution ya muy retrasada en la industria del software. 

El siguiente ano debera demostrar ser un perfodo muy interesante y de intenso aprendizaje. 

14. Version y actualizaciones 

Expuse 1.17 en el Linux Kongress, realizado el 21 de Mayo de 1997. 

Agregue la bibliograffa el 7 de Julio de 1997. 

Puse la anecdota de la Conferencia de Perl el 18 de Noviembre de 1997. 

Sustitui el termino de "software gratuito" por el de "fuente abierta" el dia 9 de Febrero de 
1998 en la version 1.29. 

Agregue la section "Epflogo: Netscape Adopta el Bazar!" el dia 10 de Febrero de 1998 en la 
version 1.31. 

Elimine la grafica de Paul Eggert sobre GPL vs. Bazar como respuesta a argumentos reiterados 
por parte de RMS el dia 28 de Julio de 1998. 

En otras revisiones he incorporado cambios editoriales menores y corregido algunos detalles. 



